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ABSTRACT 


This  thesis  investigates  the  design,  communication,  and 
allocation  considerations  for  implementing  a  distributed 
group  expert  system  on  a  Local  Area  Network.  A  model  system 
called  GESP  (Group  Expert  System  Prototype)  was  implemented 
in  Prolog  on  a  microcomputer  LAN  to  be  used  as  a  working 
platform.  From  observations  of  the  model,  conclusions  have 
been  drawn  concerning:  (1)  the  architecture  of  the  expert 
system  software  required  to  support  an  interactive  group 
expert  system;  (2)  implications  of  expert  system  to  expert 
system  communication;  and  (3)  the  optimum  allocation  strategy 
of  expert  systems  to  nodes.  Due  to  the  lack  of  a  distributed 
operating  environment  in  which  to  implement  the  model, 
efficiency  has  been  sacrificed  for  operability.  Although  GESP 
is  not  a  fully  practical  implementation  of  a  group  expert 
system,  it  should  as  a  minimum  provide  a  functional  framework 
for  understanding,  analyzing,  and  designing  interactive  group 
expert  systems . 
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I .  INTRODUCTION 


A .  BACKGROUND 

Group  expert  systems  offer  tremendous  potential  support 
to  strategic  decision  making.  Top  level  managerial  decisions 
are  often  made  by  a  group  or  by  a  single  person  after 
consultation  with  a  group.  Distributed  expert  systems  can 
facilitate  group  decisions  whether  the  organizational 
structure  is  centralized  or  decentralized. 

The  issue  of  centralization  verses  decentralization 
acquires  a  new  dimension  for  debate  when  viewed  in  the 
context  of  distributed  expert  systems.  Organizational 
structure  and  behavior  clearly  surface  as  the  central  factors 
in  the  question  of  decentralization.  The  physical  location  of 
control  of  decision  making  authority  and  responsibility 
replaces  the  traditional  arguments  of  economics  verses 
enduser  productivity  as  the  platform  debate. 

The  concept  of  distributing  expert  systems  implies  that 
some  knowledge  and  responsibility  for  decision  making  is 
distributed.  On  the  smallest  scale,  all  experts  within  the 
group  may  be  located  in  the  same  building.  A  Group  Expert 
System  (GES)  implemented  on  a  local  area  network  could,  at 
the  very  least,  conserve  the  amount  of  time  spent  in  meetings 
solving  reoccurring  problems.  In  a  decentralized  organization 
implemented  on  a  large  scale,  such  as  a  wide  area  network,  a 
GES  could  realize  significant  savings  in  timeliness  and 
effectiveness  of  organizational  decisions. 

Distributed  expert  systems  have  many  of  the  same  design 
and  implementation  problems  as  other  types  of  distributed 
systems.  Attempts  to  optimize  performance  within  constraints 
are  key  considerations.  Typical  problems  include:  the 
physical  location  of  resources,  replication  of  data, 
interprocess  and  intermodule  communications,  and  the 
determination  of  the  optimal  number  and  location  of  nodes. 

1 


\ 


B.  OBJECTIVES 

This  study  will  looks  at  the  issues  related  to  analyzing, 
designing,  and  implementing  a  distributed  group  expert 
system.  Some  of  the  major  issues  addressed  are  how  domain 
concepts,  rules  /  heuristics,  and  control  strategies  are 
distributed  based  on  system  and  communication  costs. 

C .  RESEARCH  QUESTIONS 

The  primary  research  question  is  one  of  basic 
implementation.  Is  the  implementation  of  a  distributed  expert 
system  possible  on  a  Local  Area  Network? 

If  LAN  implementation  is  possible,  what  should  be  the 
general  architecture? 

What  are  the  implications  of  node  to  node  communication 
and  of  interprocess  and  intermodule  communication?  Also,  what 
are  the  implications  of  expert  system  to  expert  system 
communication  including  calling  processes,  rule  passing,  data 
passing,  and  interactive  expert  systems? 

The  final  question  deals  with  the  actual  distribution  of 
systems .  What  is  the  optimum  allocation  strategy  of  expert 
systems  to  nodes? 

D.  SCOPE 

A  networked  prototype  distributed  expert  system  has  been 
implemented  on  six  nodes  of  a  Local  Area  Network.  The 
prototype  system  is  called  GESP,  Group  Expert  System 
Prototype.  GESP  solves  a  meta  problem  which  is  a  security 
clearance  screening  for  employees.  It  employs  multiple  expert 
systems  and  multiple  knowledge  domains.  Implementation  of 
GESP  was  constrained  by  the  operating  system  of  the  IBM  PC 
LAN,  which  does  not  directly  support  distributed  computing. 
This  limitation  was  overcome  by  using  a  commonly  available 
drive  for  a  blackboard  as  a  means  of  communication.  Although 
GESP  was  implemented  only  on  a  Local  Area  Network,  design 
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considerations,  architecture,  allocation,  and  communications 
are  discussed  in  broader  context. 

E .  METHODOLOGY 

An  architecture  has  been  proposed  by  which  expert  systems 
can  communicate  on  a  microcomputer  Local  Area  Network  using 
a  commonly  available  drive  as  a  blackboard.  A  prototype 
system,  GESP  (Group  Expert  System  Prototype) ,  has  been 
developed  using  Prolog.  It  is  capable  of  supporting  three 
knowledge  bases.  The  model  has  been  implemented  on  a  PC  LAN 
for  six  nodes.  Implications  for  system  allocation  and 
architecture  for  group  expert  systems  have  been  induced  from 
the  model.  Optimization  formulas  from  operations  research 
have  been  used  to  conduct  studies  of  cost  and  allocation 
problems.  Formulas  for  determining  system  cost  and  allocation 
for  expert  systems  have  been  derived. 

F.  SUNNARY  OF  FINDINGS 

This  study  has  shown,  by  actual  implementation  of  a  model 
system,  that  implementation  of  distributed  expert  systems  on 
a  Local  Area  Network  is  possible.  The  implementation  requires 
an  architecture  consisting  of  a  communication  structure,  a 
meta  expert  system  to  decompose  the  problem,  consult 
appropriate  expert  systems,  and  synthesize  a  solution,  and 
individual  expert  systems  to  form  solutions  within  their 
respective  domains.  It  has  also  been  shown  that  group  expert 
system  allocation  can  be  optimized  by  minimizing  system  cost. 
A  method  of  determining  expert  system  cost  has  been 
demonstrated . 

G.  ORGANIZATION  OF  STUDY 

The  remaining  chapters  will  describe  the  thesis  research. 
Specifically,  Chapter  II  presents  an  introduction  to  group 
expert  systems.  It  provides  an  overview  of  expert  system 
support  for  group  decision  making  and  supports  the  use  of 


artificial  intelligence  in  group  decision  support.  Chapter 
III  describes  the  architecture  used  in  the  model  group  expert 
system  and  proposes  a  structure  for  group  expert  systems  in 
general.  Chapter  IV  presents  communication  and  allocation 
considerations  for  group  expert  systems.  It  details  a  method 
for  measuring  system  cost  and  thereby  allocating  expert 
systems  to  nodes  on  a  network.  Chapter  V  draws  conclusions 
from  this  study  and  proposes  directions  for  future  research. 


II.  GROUP  EXPERT  SYSTEMS 


Group  expert  systems,  GES,  represent  the  next  generation 
of  intelligent  systems  which  will  provide  support  to 
management.  Current  expert  systems  operate  on  a  stand  alone 
basis.  Each  expert  system  has  problem  solving  expertise  in 
only  a  specific  domain.  However,  strategic  decision  making  in 
management  often  requires  the  coordinated  assessment  and 
evaluation  of  multiple  areas  of  managerial  expertise.  The 
development  of  group  expert  systems  can  greatly  enhance  the 
quality  and  timeliness  of  strategic  decision  making. 

Group  expert  systems  function  in  a  similar  manner  as  do 
group  decision  support  systems,  GDSS.  There  has  been  some 
debate  about  whether  or  not  an  effective  decision  support 
system  is  in  fact  an  expert  system.  The  use  of  expert  systems 
as  decision  support  systems  is  the  motivation  to  develop 
group  expert  systems .  Expert  systems  represent  "tremendous 
potential  in  providing  the  ultimate  assistance  to  decision 
makers  involved  in  serious  business  activities".  (Isett, 
1985,  p . 21 ) 

Waterman  (1986,  pp. 10-12)  suggests  that  there  are  five 
advantages  to  substituting  artificial  expertise  for  human 
expertise.  First  of  all,  artificial  intelligence  is 
permanent.  Human  experts  must  constantly  exercise  their 
skills  in  order  to  maintain  proficiency.  System  code  does  not 
decay  through  lack  of  use.  Expert  systems  are  not  affected  by 
personnel  turnover.  If  a  manager  leaves  the  firm,  that 
expertise  also  perishes.  Once  an  expert  system  is  coded, 
expertise  becomes  corporate  knowledge. 

Secondly,  artificial  expertise  is  easily  portable. 
Transferring  expert  knowledge  from  one  human  being  to  another 
is  difficult,  costly,  and  time  intensive.  Porting  artificial 
intelligence  from  one  location  to  another  is  as  simple  and 
cheap  as  copying  a  program.  Further  more,  less  experienced 
managers  gain  knowledge  through  the  use  of  expert  systems. 
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Documentation  of  knowledge  is  another  advantage.  It  is 
much  simpler  to  document  system  code  than  to  thoroughly 
explain  an  expert's  thought  process. 

Artificial  expertise  is  more  consistent  and  reliable. 
Artificial  intelligence  does  not  perform  differently  in  a 
crisis  situation  because  of  stress,  time  pressures,  or 
emotional  factors. 

Finally,  artificial  expertise  is  cheaper  than  managerial 
expertise.  Portability  is  a  major  factor  contributing  to  its 
low  cost.  It  is  far  more  expensive  to  hire  additional 
managers  to  satisfy  need  for  expertise  at  multiple  locations. 

In  addition  to  the  advantages  described  above.  Waterman 
also  lists  five  drawbacks  to  using  artificial  expertise. 
These  disadvantages  apply  to  stand  alone  expert  systems.  Some 
of  these  will  be  eliminated  by  employing  GES . 

Creativity  and  adaptability  go  hand-in-hand.  There  is 
still  much  progress  to  be  made  in  developing  systems  that  can 
learn  and  adapt  to  new  situations.  Group  expert  systems  go  a 
long  way  in  adding  the  dimension  of  separate  multiple  problem 
domains.  However,  while  a  system  may  consult  another  for 
input  into  solving  its  own  problem,  it  still  may  not  adapt 
another  system's  algorithm  or  heuristic  to  its  own  internal 
solution . 

The  whole  world  concept  encompasses  two  more 
disadvantages,  the  sensory  experience  and  common  sense.  The 
human  can  look  at  the  whole  picture  at  once  and,  drawing  from 
a  wide  range  of  experiences,  see  how  each  piece  fits.  Group 
expert  systems  support  human  interaction  only  to  the  point 
necessary  to  solve  the  problem.  If  a  more  extensive  human 
interface  is  designed  for  less  structured  problems,  human 
creativity,  adaptability,  and  common  sense  can  be  maximized. 

The  final  drawback  to  artificial  expertise  is  a  narrow 
problem  focus.  Waterman  not  only  lists  narrow  focus  as  a 
disadvantage  but  as  a  criteria  for  building  expert  systems. 
{Waterman,  1986,  p.  26)  He  states,  "An  expert  system  has 


depth;  that  is,  it  operates  effectively  in  a  narrow  domain 
containing  difficult  and  challenging  problems".  This  is  true 
for  stand  alone  expert  systems.  Group  expert  systems  combine 
multiple  domains  of  expertise  to  solve  a  meta  problem.  In 
doing  so,  GES  can  support  broad  scope  strategic  management 
problems . 

A  group  expert  system  in  its  simplest  form  is  composed  of 
a  meta  expert  system,  MES,  and  multiple  single-domain  expert 
systems.  The  meta  ES  is  concerned  with  problem-domain 
relationships  and  domain-domain  relationships.  The  MES 
identifies  the  problem  to  be  solved  and  decomposes  it  into 
individual  problem  domains.  It  identifies  the  expert  systems 
whose  domains  are  pertinent  to  the  solution. 

The  problem  solving  is  then  devolved  the  remote  ES.  The 
remote  ES  reads  the  problem  devolved,  develops  a  solution, 
and  returns  the  solution  to  the  MES.  The  MES  then  synthesizes 
the  solution.  Group  Expert  System  Prototype  is  an  example  of 
how  a  GES  solves  a  meta  problem.  The  problem  in  this  thesis 
is  whether  or  not  to  grant  a  security  clearance  to  a 
particular  employee.  There  are  three  problem-domain 
relationships  associated  with  this  question.  To  conduct  a 
security  screen,  each  employee  must  successfully  complete  a 
financial  profile  study,  criminal  profile  study,  and  a 
psychological  study. 

There  are  six  expert  systems  in  the  GES,  including  the 
MES.  Three  are  in  the  credit  domain,  CREDIT_1,  CREDIT_2,  and 
CREDIT_3.  CREDIT_1  and  CREDIT_2  have  a  peer-to-peer 
relationship  within  the  domain,  and  CREDIT_3  is  independent. 
CRIME_1  is  the  criminal  domain  and  PSYCH_1  in  the 
psychological  domain.  All  domain-domain  relationships  are 
independent.  Any  dependency  that  exists  should  be  captured  in 
the  rule  base. 

The  MES,  META,  calls  other  expert  systems  to  conduct  all 
or  part  of  the  screening  process.  The  criminal  expert  system 
looks  into  the  criminal  database  and  generates  a  criminal 


record  score.  Likewise,  the  other  expert  systems  look  into 
their  respective  databases  to  calculate  scores.  All  systems 
could  use  a  centraJ  employee  database  if  it  contained 
adequate  information.  CREDIT_1  also  has  the  ability  to 
consult  CREDIT_2  to  conduct  a  more  extensive  check.  The 
remote  expert  systems  pass  their  scores  to  META  which  accepts 
them  as  inputs  to  the  meta  problem. 

The  assumption  is  that  the  problem  is  partitionable .  In  a 
group  management  decision  scenario  partitioning  is  intrinsic 
to  the  nature  of  the  problem.  If  it  were  not,  only  one 
decision  maker  would  be  required.  Strategic  management 
decisions  involve  not  only  multiple  experts,  but  often  these 
managers  are  at  remote  locations.  Group  expert  systems 
provide  a  cost  effective  platform  by  which  scarce  expert 
resources  may  be  accessed. 

The  traditional  comparison  of  expert  systems  to  decision 
support  systems  sees  two  major  differences,  how  the  systems 
are  used  and  the  types  of  problems  they  solve.  The  use  of 
expert  systems  as  decision  support  tools  is  generally 
accepted,  however  the  difference  is  that  expert  systems 
typically  replace  the  expert.  With  group  expert  systems  it  is 
not  necessary  to  eliminate  an  expert  user.  The  goal  is  to 
minimize  the  involvement  of  expert  management,  whose  time  is 
a  scarce  resource. 

The  greatest  advantage  of  GES  over  stand  alone  ES  is  the 
type  of  problems  they  can  solve.  Current  ES  are  designed  to 
solve  structured,  well-defined,  and  somewhat  repetitive 
problems  with  a  narrow  and  predictable  domain.  Data  is 
usually  symbolic,  factual,  and  procedural  in  content.  These 
ES  are  unlike  DSS  which  solve  unstructured  and  ill-defined 
problems  of  a  broad,  complex,  and  unpredictable  nature.  DSS 
support  ad-hoc  inquiries  handling  data  which  is  numerical  and 
factual  in  content.  Modification  to  a  DSS  is  more  difficult 
than  to  an  ES,  as  a  DSS  is  more  rigid. 


Group  expert  systems  provide  managers  with  the  best  of 
both  DSS  and  ES .  Distributed  expert  systems  can  interface 
with  users  at  all  nodes  on  the  network  as  do  GDSS.  The  most 
significant  factor  of  GES  is  their  ability  to  solve  broad- 
scope  problems  involving  multiple  knowledge  domains .  Group 
decision  support  systems  require  interaction  with  a  human 
expert.  Group  expert  systems  support  such  human  interaction 
when  necessary  but  do  not  require  it.  Coding  human  expertise 
frees  the  manager  to  perform  other  functions  whenever  direct 
human  involvement  is  not  required. 


s 


III.  ARCHITECTURE  FOR  GROUP  EXPERT  SYSTEMS 


In  the  arena  of  group  expert  systems,  there  is  the 
fundamental  task  of  bringing  the  system  to  the  user.  End-user 
computing  puts  AI  decision  support  systems  within  the  user's 
reach  both  physically  and  economically,  in  terms  of  both 
system  and  budget  constraints.  However,  there  has  been  much 
debate  about  the  feasibility  of  implementing  AI  systems  on  a 
PC. 

The  knowledge  domain  of  a  meta  problem  may  be  too  large 
to  fit  into  a  PC,  in  fact  it  may  be  too  broad  for  a  single 
expert  system.  Factoring  the  meta  domain  into  discrete  sub- 
domains  and  distributing  the  sub-domain  expert  systems 
across  a  network  allows  multiple  PC's  to  share  the  problem. 

The  general  architecture  required  to  support  this  concept 
consists  of  a  communication  mechanism,  a  meta  expert  system, 
and  consultant  expert  systems.  Ideally,  the  communication  is 
problem  independent,  however,  it  may  be  imbedded  within  the 
domain  expert  systems. 

The  meta  expert  system  manages  the  solution  of  the 
problem.  It  is  responsible  for  problem  acceptance  and 
validation  and  problem-domain  and  domain-domain 
relationships.  It  decomposes  the  problem  and  devolves  the 
problem  to  consultant  expert  systems.  The  meta  expert  system 
accepts  the  results  from  the  consultants  and  synthesizes  a 
solution.  The  general  architecture  is  shown  in  Figure  3.1. 

Group  expert  systems,  GES,  present  an  ideal  platform  for 
demonstrating  how  to  implement  distributed  expert  systems  on 
PC's.  The  key  to  distributing  expert  systems  is  structured 
modular  design.  There  are  three  levels  of  modularity 
applicable  to  GES.  The  first  level  is  communication.  In  order 
to  distribute  expert  systems,  they  must  be  able  to  talk  to 
one  another.  That  is,  one  system  must  call  another;  pass 
data,  rules,  solutions,  and  make  calls  to  the  operating 
system  and  the  database.  At  some  level,  at  least  one  expert 
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Figure  3.1  META  MODELING  FOR  A  GES 
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system  must  interface  with  the  user.  The  control 
communication  structure  is  located  at  the  node  where  the 
problem  originates.  The  control  takes  the  problem  input  from 
the  user,  validates  it,  and  decides  which  expert  systems  must 
be  called  to  solve  the  problem.  It  accepts  the  inputs  and 
solutions  from  the  other  expert  systems  and  uses  them  to 
solve  the  higher  level  problem.  The  communication  structures 
at  the  lower  level  expert  systems  allow  them  to  communicate 
with  the  calling  system  and  with  each  other,  as  in  consulting 
a  peer  system.  If  the  problem  requires  input  from  a  user  at 
remote  node,  as  in  a  GDSS,  a  user  interface  at  lower  level 
can  also  be  supported.  To  the  greatest  extent  possible  the 
communication  architecture  should  be  independent  of  the 
problem  to  be  solved.  The  objective  is  to  be  able  to  solve  a 
range  of  problems  with  multiple  expert  systems  within  one 
GES.  The  advantages  of  distinct  separation  of  the  problem 
from  communication  will  be  realized  in  a  multitasking 
environment.  The  communication  module  could  call  any  expert 
system  by  issuing  an  executable  command  and  then  reading  the 
expert  system  output.  Such  a  system  should  be  extendable.  It 
should  be  able  to  support  solutions  to  other  common  expert 
system  problems  which  are  independent  of  the  domain  of 
expertise.  (Biegl,  1986,  p.  279) 

The  second  level  of  modularity  is  the  problem  itself.  The 
problem  is  factored  by  partitioning  the  knowledge  domain. 
Each  expert  system  represents  a  distinct  part  of  the 
knowledge  domain  of  a  larger  problem,  as  discussed  in  the 
previous  chapter.  Expert  systems  may  interact  vertically  or 
horizontally  to  solve  the  problem.  They  may  share  a  common 
database,  pass  rules  or  information  from  their  own  unique 
database  to  other  systems,  or  pass  their  own  solution  to 
another  system  to  be  used  to  solve  a  separate  problem.  The 
top-level  system  can  collect  solutions  from  all  other  experts 
to  solve  a  meta  problem.  The  architecture  proposed  herein  is 
one  that  supports  the  solution  of  this  meta  problem  on  a  PC 


LAN.  Vertical  and  peer-to-peer  system  communication  are 
required. 

The  third  level  of  modularity  is  within  a  single  expert 
system.  The  architecture  for  distributing  a  single  expert 
system  is  best  implemented  in  a  distributed  operating  system 
environment.  The  problem  to  be  solved  by  the  system  must  be 
one  which  can  be  partitioned  into  distinct  goals.  Unique  rule 
sets  which  are  paths  to  goals  may  be  partitioned  into  modules 
separate  from  unrelated  rules  and  distributed  to  another 
processor.  The  initial  state  rules  can  be  fired  from  a  module 
located  on  a  remote  processor.  The  resultant  of  the  goal 
state  is  then  passed  back  to  the  remote  calling  module.  This 
type  of  intermodule  communication  across  remote  processors  is 
not  practical  to  implement  on  the  PC  LAN,  as  the  LAN  was  not 
designed  to  support  distributed  processing.  The  communica¬ 
tions  structure  required  to  support  an  entire  expert  system 
would  be  necessary  for  each  set  of  modules  located  on  a 
remote  processor.  The  overhead  could  only  be  justified  for 
distributing  a  single  large  expert  system.  Distributing 
multiple  expert  systems  is  far  more  interesting,  and  the 
problem  of  the  single  system  is  solved  in  much  the  same  way. 

GESP,  Group  Expert  System  Prototype,  is  the  initial 
screening  of  an  individual  for  a  security  clearance.  To  pass 
the  screening  the  candidate  must  have  a  satisfactory 
criminal,  psychological,  and  credit  records  check.  One 
criminal  record  database,  three  credit  agencies,  and  one 
psychological  record  database  are  on  the  system.  The  control 
expert  system,  META,  interfaces  with  the  user.  The  problem  to 
be  solved,  that  is  the  type  of  screening  to  be  conducted,  is 
input  by  the  user,  and  META  calls  the  appropriate  expert 
systems.  There  is  a  single  fixed  cost  associated  with 
consulting  the  criminal  expert  system,  CRIME_1,  and  likewise, 
the  psychological  expert  system,  PSYCH_1 .  However,  each 
credit  expert  system  has  a  different  cost  associated  with. 
The  top-level  system,  META,  may  select  either  CREDIT  1  or 
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CREDIT_3.  CREDIT_3  is  the  cheaper  system,  but  it  is  less 
extensive  than  CREDIT_1  and  only  used  for  lower  level 
clearances.  CREDIT_1  is  more  expensive  and  is  used  for  more 
sensitive  clearances.  It  has  the  ability  to  consult  CREDIT_2 
on  a  peer-to-peer  basis  in  order  to  obtain  a  higher  quality 
solution . 

The  first  and  most  obvious  obstacle  to  implementing  GESP 
is  the  fact  that  the  IBM  PC  LAN  operating  system  does  not 
directly  support  distributed  processing.  It  is  not  possible 
to  directly  call  an  expert  system  located  on  a  remote 
processor  or  to  directly  pass  it  data.  To  establish  system- 
to-system  communication  a  virtual  disk  was  created.  The 
virtual  disk  is  used  as  a  blackboard  to  which  all  expert 
systems  can  read  and  write.  In  this  respect  GESP  can  not 
adhere  to  modular  independence  between  the  communication 
structure  and  the  specific  problem.  A  diagram  of  GESP  is 
presented  in  Figure  3.2. 

META  calls  other  expert  systems  by  writing  the  file, 
k_file.inp.  This  file  contains  the  names  of  the  expert 
systems  to  be  called  and  all  data  necessary  to  begin 
execution.  The  other  expert  systems  use  a  polling  process  to 
look  for  this  file.  When  k_file.inp  appears,  each  system 
checks  the  time  stamp  to  see  if  the  file  is  current.  If  the 
file  is  current  it  is  opened  and  read.  Each  expert  system 
then  checks  the  list  for  membership  to  see  if  it  is  being 
called.  The  check  is  accomplished  by  using  the  member 
predicate.  If  the  membership  rule  succeeds,  the  expert  system 
begins  execution  of  the  problem.  Each  system  returns  a 
solution  by  writing  the  files  crime_l.rep,  credit_l . rep,  and 
psych_l.rep  respectively.  CREDIT_1  calls  CREDIT_2  in  the  same 
manner  using  the  file,  credit_l . inp .  CREDIT_2  responds  with 
the  file,  credit_2 . rep. 

All  systems  must  constantly  poll,  checking  the  time 
stamp,  to  see  if  they  are  being  called.  If  the  META  system 
knows  on  which  processor  each  expert  system  is  located  the 
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process  can  be  made  much  more  efficient.  META  could  make  a 
call  to  the  operating  system  telling  it  to  send  an  interrupt 
signal  to  the  desired  processors.  When  the  called  processor 
receives  the  interrupt,  it  "wakes  up"  the  polling  process. 

META,  Figure  3.3,  has  a  list  of  all  problems  that  can  be 
solved  on  the  system  in  its  database.  Any  problem  input  by  a 
user  is  checked  for  validity.  An  incorrect  problem 
submission  will  generate  an  error  message  to  the  user,  and 
the  system  will  cease  execution  and  return  to  the  initial 
state.  Input  of  a  valid  problem  begins  execution,  and  META 
will  determine  which  expert  systems  are  to  be  consulted  from 
the  database.  Each  problem  is  associated  with  a  list  of 
expert  systems  required  to  solve  it.  The  calling  file, 
k_file.inp,  is  created,  and  the  list  of  expert  systems  to  be 
called  is  included.  K_file.inp  is  then  written  to  the  virtual 
drive . 

Immediately  after  the  calling  file  is  written,  META  goes 
into  the  polling  process.  It  looks  for  a  report  file  from 
each  of  the  expert  systems  in  the  order  in  which  they  were 
called.  Polling  continues  until  a  report  file,  for  example 
crime_l.rep,  appears.  By  use  of  the  "directory"  predicate 
META  checks  the  time  stamp  on  crime_l.rep  and  compares  it  to 
the  time  in  its  database.  The  base  time  is  initialized  to 
zero  for  the  first  run.  If  the  times  do  not  match,  the  file 
is  determined  to  be  current  and  is  opened.  The  information 
provided  by  the  remote  expert  system  is  read  and  asserted  to 
the  database.  The  polling  process  is  again  initiated,  and  the 
procedure  is  repeated  until  all  expert  systems  have  reported. 
The  time  stamp  of  the  latest  read  of  the  report  file  is 
recorded. 

META  proceeds  to  evaluate  the  reports  to  determine  if  the 
candidate  will  satisfy  the  security  screening  requirements. 
Each  expert  system  returns  a  score  which  is  the  measure  of 
the  candidates  performance  in  each  area.  Point  levels  are 
awarded  for  discrepancies.  For  each  area  of  evaluation  there 
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is  a  threshold  level  above  which  the  candidate  fails.  The 
scores  are  then  totaled.  There  is  likewise  a  failing 
threshold  for  total  score,  accounting  for  the  synergistic 
effect.  It  is  possible  that  one  might  pass  each  area  by  a 
narrow  margin  but  fail  for  having  done  significantly  poorly 
in  more  than  one  area.  META  then  displays  the  results  to  the 
user . 

CRIMEJL,  PSYCH_1,  and  CREDIT_3,  Figures  3.4,  3.5,  and  3.6 
respectively,  are  very  similar  in  structure.  They  are  called 
by  and  report  directly  to  META.  CRIME_1  will  be  used  as  an 
example.  It  uses  the  "directory"  predicate  to  poll  the 
virtual  drive  as  does  META.  It  also  uses  the  same  time  stamp 
checking  procedure  and  the  same  membership  check.  Upon 
determining  the  validity  of  the  call,  it  executes  a  criminal 
record  check.  Upon  determining  a  score,  it  creates  the  file 
crime_l.rep  including  the  score  and  writes  the  file  to  the 
blackboard. 

CREDIT_1 ,  Figure  3.7,  is  called  by  and  reports  to  META 
by  the  same  process  as  do  CRIME_1  and  PSYCH_1 .  The  unique 
feature  of  CREDIT_1  is  peer-to-peer  communication.  It  is  this 
added  feature  which  is  the  primary  contributor  to  its  higher 
consultation  cost.  The  decision  to  consult  may  be  delegated 
to  a  lower  level  or  may  exist  at  that  lower  level  as  an 
intrinsic  part  of  the  problem.  In  this  case,  the  more 
extensive  credit  expert  system  decides  whether  or  not  to 
initiate  further  investigation  based  on  its  own  first-cut 
findings.  The  decision  to  consult  CREDIT_2,  Figure  3.8,  is 
based  on  a  threshold  score.  If  the  candidate  fails  the 
initial  check,  a  more  detailed  investigation  can  be  prompted 
to  see  if  a  failing  score  is  warranted. 

The  structure  of  the  code  used  to  call  CREDIT_2  and  to 
make  and  receive  its  report  is  the  same  as  that  of  the  higher 
level  expert  systems.  Only  the  names  of  the  calling  and 
reporting  files  are  changed.  The  call  to  an  expert  system  at 
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the  peer  level  can  be  made  in  the  same  way  as  a  vertical 
call . 

The  key,  again,  is  modularization.  The  communication 
structure  is  generalized  within  the  problem,  such  that  it 
supports  vertical  and  horizontal  interfaces.  The  problem  with 
implementation  on  non-distributed  and  non-multitasking 
microcomputer  network  is  the  necessity  of  writing  to  the 
blackboard.  A  problem-specific  file,  such  as  crime_l.rep, 
does  not  allow  complete  separation  of  problem  and 
communication . 

A  better  example  of  modularity  is  the  consulting  module 
in  CREDIT_2 ,  "cal^soln" .  For  the  purposes  of  the  prototype, 
a  resultant  score  is  asserted  rather  than  conducting  a 
consultation  of  an  actual  database: 

calc_soln:-  asserta (score (160) ) . 

This  module  is  called  from  the  main  program  module  and  is 
completely  independent  from  all  other  code.  By  only  asserting 
a  score,  simplicity  of  the  model  is  maintained,  and  most 
importantly,  the  generic  nature  of  this  module  is 
demonstrated.  The  string  "calc_soln: -"  can  be  followed  by  a 
call  to  any  credit  database.  In  fact,  the  predicate  can  be 
followed  by  any  argument,  however  unrelated,  as  this  module 
is  not  coupled  to  any  other.  Creating  an  open  environment 
will  maximize  the  ease  with  which  even  third  party  expert 
systems  can  be  incorporated  into  the  GES.  (Silverman,  1986, 
P-  28) 

The  credit  check  may  even  be  conducted  by  a  separate 
expert  system  which  is  called  by  calc_soln.  By  doing  so  the 
solution  of  a  single  problem  is  further  separated  from  the 
group  communication  structure. 

GESP  presents  a  basic  architecture  for  supporting  group 
expert  systems.  Although  it  was  not  possible  to  obtain  the 
lowest  degree  of  coupling  and  highest  degree  of  problem 
independence  within  the  constraints  of  the  PC  LAN,  the 
advantages  that  can  be  derived  from  modular  design  have  been 


demonstrated.  Through  the  use  of  structured  modular  design 
and  functional  independence  at  all  three  levels  of 
modularity,  it  is  possible  to  implement  group  expert  systems 


IV.  COMMUNICATION  AND  ALLOCATION  CONSIDERATIONS 


Once  the  decision  has  been  made  to  employ  a  group  expert 
system  the  question  of  where  to  locate  it  arises.  Certainly 
there  are  external  environmental  factors  affecting  system 
location,  such  as  organizational  structure  and  politics. 
However,  the  focus  here  will  be  strictly  on  system  issues  for 
which  there  is  an  algorithmic  solution.  The  question  of 
optimum  allocation  strategy  applies  whether  implementing  a 
group  expert  system  on  an  existing  hardware  suit  or  designing 
an  entirely  new  system  including  hardware.  The  question  to  be 
answered  here  is,  "What  is  the  optimum  allocation  strategy  on 
a  network  for  a  group  expert  system  involving  multiple  expert 
systems"? 

There  is  no  good  allocation  strategy  presently  in  use. 
Saj-nicole  Joni,  director  of  consulting  services  at  Gold  Hill 
Computers,  Inc.  in  Cambridge,  Massachusetts,  has  stated  that 
there  is  no  threshold  number  of  rules  or  processing  speed 
that  can  be  used  to  determine  where  the  expert  system  should 
reside  (Williamson,  1987,  p.  56).  If  Joni's  statement  is 
true,  how  then  are  systems  to  be  allocated? 

The  key  to  answering  the  question  of  allocation  is  to 
think  in  terms  of  maximizing  benefits  and  minimizing  costs. 
Networked  expert  systems  benefit  from  the  modularity  of 
distributed  processing  as  do  other  distributed  systems. 
Modular  design  and  distribution  achieve  the  greatest 
advantages  over  stand-alone  systems.  These  benefits,  as 
discussed  in  detail  in  previous  chapters,  include  an  in¬ 
creased  problem  scope  and  knowledge  base,  multiple  knowledge 
domains,  and  the  ability  to  physically  distribute  expertise. 

The  disadvantage  of  distributing  expert  systems  is  the 
same  as  that  for  any  other  type  of  system,  and  that  is 
overhead  cost.  Overhead  cost  is  incurred  when  an  expert 
system  executing  on  a  processor  makes  a  call  to  the  operating 
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system,  the  database,  or  communicates  with  another  expert 
system  residing  on  a  different  processor. 

Expert  system  overhead  cost  is  analogous  to  interprocess 
communication,  as  discussed  by  Wesley  W.  Chu,  et  al,  in  that 
system  performance  can  be  maximized  by  minimizing  system 
cost.  Interprocessor  communication  in  distributed  systems  is 
much  like  paging  in  memory  systems .  IPC  can  be  increased  to 
the  point  where  thrashing  takes  place.  The  system  becomes 
saturated  by  overhead,  and  performance  is  degraded.  Chu 
suggests  an  integer  programming  approach  to  the  problem  of 
task  allocation  as  a  means  of  minimizing  IPC  and  maximizing 
system  performance.  Chu' s  objective  function  (Chu  and 
Holloway,  1980,  p.  57)  for  minimizing  IPC  cost,  in  the 
general  case,  is  as  follows: 

Cost  (X)  =  ZkZi  ^ik5^*  +  ^i<k2j<i  (wvi  jdkixikx  jl)  ] 

Subject  to: 

^sixik  ^  Rk'  memory  constraint,  and 

^uixik  ^  Tk'  real-time  constraint. 

Where : 


q  =  processing  cost 

x  =  assignment  of  ES^  to  node  k,  0  or  1 
w  =  normalization  factor 


v  =  volume  of  communication 


d  *  distance  between  nodes.  (Chu  and  Holloway, 
1980,  p.  62) 


task  allocation  minimizes  IPC  in  conventional 


distributed  systems,  the  allocation  of  expert  systems  to 
nodes  and  the  allocation  of  problems  to  expert  systems 
minimizes  IPC  in  the  specific  case  of  distributed  expert 
systems.  An  integer  programming  technique  similar  to  the  one 
presented  by  Chu  can  be  used  to  solve  the  expert  system 
allocation  problem.  Processing  costs  and  communication  c^sts 
are  calculated  for  every  expert  system  at  every  node. 
Assignment  of  expert  systems  to  nodes  is  based  on  minimizing 
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the  objective  function,  and  therefore,  maximizing 
perform  ce .  The  system  cost  function  for  expert 

system  .3  comprised  of  two  cost  components,  processing  cost 
and  communication  cost.  One  of  the  major  tasks  of  using  the 
integer  programming  model  is  the  evaluation  of  the  system 
processing  costs.  Studies  of  literature  concerning  task 
allocation  in  a  distributed  environment  have  suggested  the 
following  list  of  variables  pertinent  to  system  cost: 

N  =  execution  frequency  of  a  module 
AET  =  accumulative  execution  time 
r^  =  number  of  expert  system  rules 
s^  »  I/O  and  level  of  coupling  among  rules 
MIL  =  machine  language  instructions  (Chu  and  Lan, 

1984,  p.  692) 

tp (A)  *  processor  turnaround  time 
t  (A)  =  task  turnaround  time  (Shen  and  Tsai,  1985,  p. 
198) 

tk  *  power  of  processor  at  the  node 

Other  considerations: 

Growth  potential 
Memory 

The  values  of  r^  and  s^  can  be  found  by  using  the  A* 
algorithm,  which  employs  a  cost  function  and  an  evaluation 
function,  as  described  later  in  this  chapter.  N  is  captured 
in  s^  through  the  cost  function,  and  therefore  becomes 
statistically  insignificant  and  can  be  dropped.  AET,  tp (A) , 
and  t  (A)  are  inversely  proportional  to  t^.  AET  is  expressed 
in  machine  language  instructions,  MIL.  Machine  instructions 
vary  from  processor  to  processor.  Measuring  MIL  across 
heterogeneous  processors  could  require  a  significant 
normalization  effort.  Measuring  execution  cost  with  respect 
to  the  expert  system  rather  than  a  specific  processor's 
instruction  set  provides  a  uniform  measurement,  and  MIL  is  r^ 
/  t^.  Considerations  such  as  growth  and  memory  are  determined 
by  the  power  of  the  processor  at  the  node,  t^.  'rocessing 
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cost  is  the  execution  time  of  an  expert  system  on  a 
processor.  Execution  time  is  a  function  of  the  number  of 
rules  fired  to  solve  a  given  problem  by  an  expert  system,  the 
level  of  coupling  among  the  rules,  the  amount  of  I/O 
required,  and  the  power  of  the  CPU  at  the  node.  The  following 
formula  for  processing  cost  was  derived  as  part  of  this 
study : 

qik  =  f(r.,  Si,  tk) 

Combining  the  cost  function  and  the  evaluation  function 
with  respect  to  the  power  of  the  processor  yields  the  cost  of 
execution,  q^- 

The  cost  of  processing  an  expert  system  is  directly 
proportional  to  the  number  of  rules  in  that  expert  system. 
Any  expert  system  will  eventually  test  all  its  rules,  even  if 
the  level  of  coupling  among  the  rules  is  zero.  Certain 
queries  will  find  an  immediate  match,  while  others  will  be 
matched  by  the  latter  rules.  On  the  average  fifty  per  cent  of 
the  rules  in  a  system  will  be  fired.  The  cost  of  executing  a 
system  is  driven  up  by  the  total  number  of  rules,  r^ . 

q. .  oo  r  ■ 

lk  1 

The  level  of  coupling  is  a  factor  which  weights  the 
rules.  Rules  that  are  highly  coupled,  that  is,  one  rule  fires 
one  or  more  successive  rules,  are  more  costly  to  execute. 
Rules  which  perform  I/O  functions  utilize  more  system 
resources  than  those  that  do  not.  The  number  of  rules  is 
weighted  by  the  level  of  coupling  and  amount  of  I/O,  and 
therefore,  r^  is  multiplied  by  s^ .  System  cost  is  directly 
proportional  to  s^. 


cjik  <»  Si  and 


qik  ~  riSi 


The  relationship  between  execution  cost  and  the 
processing  power  is  straight  forward.  As  the  power  of  the  CPU 
increases,  ceteras  paribus,  the  time  of  system  execution 
decreases.  System  cost  is  inversely  proportional  to  tk. 

qik  oo  !  /  tk 
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If  expert  system  (1)  is  located  on  node  (k)  ,  then  the 
processing  cost,  qa,  of  running  problem  (a)  on  expert  system 
(i)  located  on  processor  (k)  is  q^. 

<Uk  =  ri  si  /  fck 
r^  =  number  of  rules  in  ES^ 

s^  =  I/O  overhead  and  level  of  coupling  among 
rules  in  ES^ 

t^  =  power  of  CPU  at  node  k 

For  the  general  case,  the  total  system  processing  cost 
for  any  expert  system  located  on  any  node  is  captured  in  the 
formula : 

Processing  cost  = 

where,  q  is  the  cost  of  processing  expert  system  (i)  on 
processor  (k)  ,  for  all  i  and  k,  and  from  the  assignment 
matrix,  x  =  1  if  expert  system  (i)  is  on  processor  (k)  and  0 
if  it  is  not. 

The  number  of  rules  fired  and  the  level  of  coupling  among 
the  rules  depends  on  the  control  structure  of  the  expert 
system.  Expert  systems  may  use  any  of  a  number  of  control 
structures  for  search;  depth-first,  breadth-first, 
optimization,  best  first,  branch-and-bound,  or  A*  search. 
Depending  on  the  type  of  problem  and  the  control  structure 
used,  one  can  determine  the  state  of  search  of  a  problem 
using  tools  such  as  evaluation  functions  or  cost  functions. 
When  designing  an  expert  system,  these  functions  help  to 
clarify  which  search  structure  is  best  for  a  given  problem  by 
identifying  the  number  of  states,  levels  of  logic,  which  must 
be  transversed  in  order  to  reach  a  goal  state.  An  evaluation 
function  can  numerically  represent  the  distance  from  the 
goal,  at  any  state  in  the  search. 

The  concept  of  measuring  distance  from  the  goal  by  number 
of  states  is  also  useful  in  determining  processing  cost.  Each 
state  transversed  to  reach  the  goal  requires  an  additional 
number  of  rules  fired.  Different  search  structures  will  fire 
a  different  number  of  rules  for  a  problem,  but  regardless  of 
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the  type  of  search,  the  distance  from  the  goal  can  be 
measured.  By  using  an  evaluation  function  one  can  determine 
the  number  of  states  required  to  solve  a  problem  by  an  expert 
system. 

To  find  r^  and  Sj_,  each  state  must  be  evaluated  in  terms 
of  the  number  of  rules  fired,  the  level  of  coupling  of  the 
rules,  and  I/O  overhead.  Optimal  path  searches,  of  which 
there  are  two,  are  best  suited  to  state  evaluation  in  terms 
of  processing  costs .  The  branch-and-bound  search  employs  an 
evaluation  function,  and,  as  do  all  evaluation  functions,  it 
measures  cost  in  terms  of  distance  to  the  goal.  This 
"strategy  may  jump  around  among  states  . . .  but  it  has  a  nice 
property:  the  first  path  to  the  goal  is  guaranteed  to  be  the 
lowest-cost  path  to  the  goal"  (Rowe,  Ch.  9  p.  9)  .  Evaluation 
functions,  however,  account  only  for  distance  in  terms  of 
states.  With  respect  to  expert  systems,  they  do  not  account 
for  the  number  of  rules  fired  in  a  given  state  or  the  cost  of 
executing  operators  within  that  state.  Operators  which 
require  I/O  have  a  higher  system  cost  associated  with  them 
due  to  the  difference  in  speed  of  CPU  processing  versus 
database  access  and  calls  to  the  operating  system.  The  I/O 
operators  can  be  converted  to  standard  work  units  for  system 
design  and  tuning  purposes,  as  will  be  discussed  later. 

The  A*  (A  star)  search  employees  both  an  evaluation 
function,  to  account  for  search  distance,  and  a  cost  function 
to  assign  values  to  the  states  based  on  the  cost  of  the 
operators  within  the  states. 

Combining  the  values  of  the  evaluation  and  cost  functions 
provides  a  method  of  measuring  r^  and  s^.  Both  functions 
should  use  the  same  unit  of  measure.  The  processing  cost 
function  measures  the  execution  time  of  equivalent 
instructions  on  a  processor  in  terms  of  rules  fired  and  I/O 
requirements.  Therefore,  if  the  evaluation  gives  the  distance 
to  the  goal,  the  number  of  states  to  the  goal,  and  the  cost 
function  assigns  a  value  to  each  state,  based  on  rules  fired 


and  I/O  overhead  the  combination  of  the  two  yields  the  lowest 
cost  of  processing  a  given  problem  on  a  node. 

A  specific  example  of  how  this  is  done  can  be 
demonstrated  using  the  prototype  distributed  expert  system. 
The  processing  cost  for  expert  system  CRIME_1  to  solve 
problem  (a)  is  calculated  as  follows: 

^ik  *  ri  si  /  *"k 

Using  A*  search  to  trace  r^  and  s^  through  each  state 
within  an  expert  system  is  a  variation  of  the  state-space 
search  method,  applied  specifically  to  expert  system 
allocation.  The  purpose  of  this  application  of  state-space 
search  is  not  to  find  the  optimal  weak  homomorphism  (Shen  and 
Tsai,  1985,  p.  200)  but  to  measure  the  processing  cost 

of  a  possible  system  allocation  or  that  of  an  existing 
system.  There  are  significant  system  design  implications  for 
the  A*  algorithm  which  will  be  discussed  in  the  concluding 
chapter . 

State-space  search  allows  one  to  find  the  cost  of  the 
path  to  the  goal  for  a  single  problem.  Applying  the  integer 
programming  method  to  the  result  of  the  A*  algorithm  sums  the 
processing  costs  of  all  problems  that  can  be  executed  by  all 
expert  systems  at  a  given  node  to  determine  the  system 
processing  cost  for  that  node.  The  system  objective  function 
can  now  optimize  processing  cost  for  all  problems  over  all 
nodes.  It  is  now  possible  to  allocate  systems  to  nodes  based 
on  minimizing  processing  cost,  however,  an  optimum  allocation 
strategy  must  also  consider  communication  costs. 

Communications  costs  for  the  expert  are  decomposed  into 
volume  and  cost  per  unit.  Volume  is  the  amount  of 
communication  required  between  expert  systems,  C^j,  for 
expert  systems  (i  and  j)  .  Cost  per  unit  volume,  C^,  is  the 
cost  of  communicating  between  two  processors,  k  and  1. 

Volume  of  communication  is  not  problem  dependent  when 
allocating  expert  systems  to  nodes.  The  primary  consideration 
is  the  volume  of  communication  necessary  to  create  the 
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interface  between  expert  systems  regardless  of  the  problem  to 
be  solved.  Volume  becomes  problem  dependent  at  the  task 
allocation  level.  That  is,  how  to  decide  which  problem  should 
be  run  on  which  expert  system,  based  on  cost  verses  solution 
payback.  Volume  becomes  problem  dependent  at  the  system 
level  only  if  the  system  solves  a  single  problem  or  if  task 
allocation  is  static.  Both  of  these  situations  are 
uninteresting  from  an  interactive  GDSS  point  of  view  and  will 
not  be  discussed  further.  A  static  allocation  problem  can  be 
solved  using  the  dynamic  allocation  model. 

The  formula  for  determining  communication  cost  is 
developed  by  combining  volume  of  communication  with  cost  per 
unit  volume  with  respect  to  the  assignment  matrix: 

Communication  cost  =  <ci j(-]clxikx jl> 

Other  variables  for  communication  cost  suggested  by 
previous  studies: 

V  =  average  number  of  words  communicated 
M-F  =  number  of  updates 

L  =  average  number  of  words  per  update  (Chu  and  Lan, 
1984,  p.  692) 

v  and  L  are  captured  by  Ci j ,  and  M-F  is  represented  in  Ckl . 

Total  system  cost  is  realized  by  combining  processing  and 
communication  costs: 

Total  system  cost  =  I]cI1[qijXij  +  jCklxiJcx j^_)  ] 

Optimum  allocation  can  be  realized  by  minimizing  total 
cost  subject  to: 

real-time  constraint: 

Efu-^x^kS;  T^)  ,  k  =  l,...,n 
where,  u  =  processing  time  required  by  ES  (i) 

T  =  time  constraint  for  processing  ES  (i)  on  node 
(k)  and, 

memory  constraint: 

£(s^Xj^  ^  Rfc ),  k  =  1 ,  •  •  • , n 

where,  s  =  memory  required  by  ES(i) 
r  =  maximum  memory  in  node  k. 


►l 

g 


E 


B; 


T 


LrL| 


The  expert  system  allocation  formula  is  similar  to  the 
general  format  for  distributed  systems  derived  by  Chu  (1980) : 

Cost  (X)  =  IkIi[qik.  +  xik+  Ii<kIj<1  (wvijdikxik.xjl)  ]  . 

For  the  model  system  implemented  on  the  LAN,  distance  (d)  is 
considered  constant  and  insignificant  to  communication  cost 
and  will  be  ignored.  As  well,  the  normalization  factor  (w)  is 
unnecessary,  as  units  of  measure  are  consistent  throughout 
the  model . 

To  look  at  a  specific  problem  on  the  model,  suppose  the 
problem  is  problem  "a".  There  is  some  probability  associated 
with  each  expert  system  in  the  model  which  is  the  likelihood 
that  the  system  will  be  called  to  solve  problem  a.  There  is 
likewise  some  probability  associated  with  each  expert  system 
for  every  problem  solvable  by  the  distributed  expert  system 
model.  The  probability  that  a  system  is  called  to  solve  a 
problem  can  be  applied  to  the  processing  costs  and 
communication  costs  of  executing  that  problem  on  the 
individual  expert  system.  Summing  the  costs  of  every  expert 
system  called  to  solve  the  problem  solution  yields  the  cost 
of  solving  that  individual  problem  on  the  distributed  system. 
Summing  the  costs  of  all  the  individual  problems  on  the 
system  determines  the  total  system  cost. 

Cost  =  ^k2i[qikxik+  ^jc^i  jCklxikXj1)  ] 

The  distributed  expert  system  model  has  four  expert 
systems;  META,  CRIME_1,  CREDIT_1,  and  CREDIT_2,  to  be 
referred  to  in  the  equation  as  ESI,  ES2,  ES3,  and  ES4 
respectively.  The  probability  that  expert  system  1  is  called 
is  PesI'  the  Probability  that  problem  a  is  executed  is  Pa.  As 
discussed  in  the  previous  chapter,  all  nodes  communicate  via 
the  blackboard,  which  will  be  represented  as  node  5.  During 
each  call,  a  node  both  writes  to  and  reads  from  the 
blackboard.  Therefore,  communication  costs  between  nodes  1 
and  2  via  node  5  is  20^5+2025 • 
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The  problem  of  optimizing  the  allocation  of  problems  on 
the  system  can  be  solved  by  the  following  equation: 

Cost  -  PEsl(Paqi+  Pbqx+  Pcqi)  + 

PES2 [Pa (q2+2C15+  2C25)  +  Pfe (q2+2C15+2C25)  + 


pc<q2 


+  2C, 


+  2Co  c ) ]  + 


PES3{pa[q3+  2C15+  2C35+  PES4 (q4+  2C35+  2C45)]  + 

Pb^q3+  2C15+  2C35+  peS4  *q4  +  2C35+  2C45^  + 

Pc^q3+  2C15+  2C35+  PES4 (q4+  2C35+  2C45) ^ 

The  problem  of  optimizing  the  allocation  of  expert 

systems  to  nodes  is  more  complicated  when  considering  the 
processing  and  communication  costs  for  the  entire  set  of 
problems  to  be  solved  by  the  expert  systems.  The  above 
equation  must  now  be  solved  for  each  expert  system  on  each 
node,  and  the  equation  is  expanded  as  follows: 

Cost  =  PESi<paqllxl+  pbqllxl+  pcqllxl+  paq12x2+  pbql2x2+ 
pcq12x2+  Paq13x3+  Pbq13x3+  Pcq13x3+  Paq14x4+ 
pbq14x4+  Pcq14x4>  + 

PES2 ^pa *q21x2+  q22x2+  q23x2+  q24x2+  2C15+  2C25^+ 
pb(q21x2+  q22x2+  q23x2+  q24x2+  2C15+  2C25)+ 
Pc(q21x2+  q22x2+  q23x2+  q24x2+  2C15+  2C25,+ 
PES3{PaCq31x3+  q32x3+  q33x3+  q34x3+  2C15+  2C35+ 
PES4<q41x4+  q42x4+  q43x4+  q44x4+  2C35 

2C45)]+  pbfq3iX3+  q32x3+  q33x3+  q34x3+ 
2C15+  2C35+  PEs4(q41x4+  q42x4+  q43x4+ 
q44x4+  2c35+  2C45^ 1 +  pc^q31x3+  q32x3+ 
q33x3+  q34x3+  2c15+  2C35+ 

PES4(q41x4+  q42x4+  q43x4+  q44x4+  2C35+ 

2c45) ] } 


Assume  ES-^  is  located  on  node  1,  ES2  on  node  2,  ES3  on 
node  3,  and  ES4  on  node  4  with  node  5  as  the  blackboard. 
Problem  "a"  will  be  solved,  and  all  expert  systems  are  called 


to  reach  a  solution. 


Cost  «  qil  +  (q22  +  2c15  +  2c25^  +  ^q33  +  2C15  + 

(q44  +  2c35  +2c45) ] 


For  problem  (a)  on  q^  there  are  83  rules.  These  rules 
perform  I/O  functions  or  are  coupled  to  other  rules  51 
times.  The  power  of  the  8086  processor  on  the  IBM  PC  LAN  is 
4 . 77MHz . 

*11  “  ri  si  >  Gk 

-  83  x  51  /  4.77  -  4233  /  4.77  =  887.42 

+ 

q22  -  40  x  26  /  4.77  -  1040  /  4.77  =  218.03 
+ 

2Ci5  -  2(C±jCkl) 

=  2(2x2)  =8 

+ 

2C25  -  2(1  x  2)  =4 

+ 

q33  -  80  x  46  /  4.77  =  3680  /  4.77  -  771.49 
+ 

2C35  -  2(1  x  1)  =2 

+ 

q44  -  40  x  26  /  4.77  =■  1040  /  4.77  «  218.03 
+ 

2C45  -  2(1  x  1)  =2 

Cost  -  887.42  +  218.03  +  8  +  4  +  771.49  +  2  +  218.03  +  2 
=  2110.97 

For  this  example  the  level  of  coupling  was  determined  by 
the  number  of  times  a  rule  fires  additional  rules  or  invokes 
an  I/O  function.  The  module  "get_credit_l"  has  a  coupling 
value  of  6. 

get_credit_l : - 

#  directory  ('  c :  \credit_l .  rep' T,D, _)  , 

#  base_time_c, 

#  base  date  c. 


i  |m*  K*.h*Ji*  1 


#  new_time_c (T)  , 

#  new_date_c (D) , 
asserta (base_d_c <D) ) , 
asserta (base_t_c (T) ) , 

#  shell ('copy  c:  credit_l . rep' ) , 

open (H, ' credit_l . rep, r) , 
read_val (H)  , 

close (H) . 

There  are  two  calls  to  the  operating  system  (*)  and  four 
additional  rules  fired  (#).  It  is  assumed  that  vertical 
communications  cost  twice  as  much  as  peer-to-peer 
communications  and  that  META  is  sending  twice  the  message 
volume  as  the  other  systems . 

The  resultant  value  is  a  magnitude.  It  can  applied  across 
heterogeneous  processors,  with  regard  to  the  value  of  q,  and 
to  dissimilar  networks,  with  regard  to  C.  The  value  of  q 
may  be  converted  to  equivalent  instructions  on  a  specific 
machine  and  the  time  of  execution  on  that  machine.  C 
represents  the  number  of  messages  sent  and  the  value  of  the 
data.  The  end  result  can  be  measured  in  terms  of  the 
standard  work  unit  (SWU) .  In  terms  of  the  interactive 
environment,  the  SWU  is  the  single  most  important  concept. 
Applications  built  within  parameters  of  the  standard  work 
unit  minimize  critical  resources  used  for  execution  and 
uniformly  apply  the  discipline  of  controlling  resource 
consumption  across  all  applications  within  the  system. 
(Inmon,  1983,  p.  75) 

A  magnitude  expressed  in  terms  of  performance 
constraints,  such  as  the  SWU,  provides  an  optimal  means  of 
allocating  expert  systems.  A  threshold  number  of  rules  or 
processor  speed  is  not  necessary,  as  the  number  of  rules, 
level  of  coupling  among  rules,  and  power  of  the  processor  are 
contained  in  the  objective  function. 

Through  the  use  of  distributed  expert  systems,  it  is 
possible  to  solve  problems  previously  thought  to  be  too  broad 
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for  expert  system  application.  A  large  knowledge  domain  may 
be  partitioned  into  distinct  areas  of  expertise  which  are 
incorporated  into  separate  expert  systems.  Overall  problem 
management  is  performed  by  the  meta  expert  system.  The  system 
allocation  function  can  be  applied  to  any  specific 
configuration  to  determine  to  determine  where  these  expert 
systems  should  reside.  If  the  problem  can  be  solved  by  more 
than  one  expert  system,  or  if  it  may  be  necessary  to  solve 
only  part  of  a  problem,  the  task  allocation  function  can 
determine  which  expert  system  should  be  called.  Integer 
programming  allows  me  to  determine  the  optimal  use  of  the 
distributed  system.  Programming  the  selection  criteria  into 
the  meta  system  automates  the  optimization  process  of  task 


V.  CONCLUSIONS  AND  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

A.  CONCLUSIONS 

This  thesis  has  shown  that  implementation  of  distributed 
expert  systems  is  possible  on  a  Local  Area  Network.  By 
distributing  expertise  within  group  expert  systems,  it  is 
feasible  to  solve  large  problems  using  artificial 
intelligence  applications  on  PC's. 

If  the  problem  domain  is  one  that  is  factorable,  then 
independent  expert  systems  can  solve  portions  of  the  problem. 
The  domain  must  be  factored  into  discrete  areas  of  expertise 
which  can  be  distributed  across  the  nodes  of  a  network. 
Solutions  from  these  expert  systems  can  be  synthesized  by  a 
single  system  to  solve  the  meta  problem. 

The  general  architecture  for  group  expert  systems 
consists  of  a  communication  structure,  a  meta  expert  system, 
and  consultant  expert  systems.  The  communication  mechanism 
should  be  independent  of  the  specific  function  of  the  expert 
systems  in  the  group.  It  is  merely  a  vehicle  to  invoke 
consultant  expert  systems,  pass  problem  information  and 
solutions,  and  perform  I/O  functions.  Vertical  communications 
between  the  meta  and  consultant  systems  and  horizontal  peer- 
to-peer  communications  between  consultant  systems  must  be 
supported . 

The  meta  expert  system  manages  the  problem  solution.  It 
identifies,  validates,  and  decomposes  the  problem.  The  meta 
system  determines  problem-domain  and  domain-domain 
relationships  and  devolves  the  problem  to  the  appropriate 
expert  systems.  When  given  a  choice  of  consultant  expert 
systems  within  the  same  domain,  it  selects  a  system  based  on 
a  cost  verses  problem  pay-back  criteria.  Inputs  from 
consultant  expert  systems  are  then  synthesized  into  a  problem 
solution  by  the  meta  system. 

The  consultant  expert  systems  read  and  validate  the 
problem  input.  These  expert  systems  may  consult  with  each 
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other  on  a  peer-to-peer  basis  during  the  formulation  of  a 
problem  solution  within  its  own  domain.  They  then  communicate 
vertically  their  individual  solutions  to  the  meta  system. 
This  general  architecture  supports  the  solution  of  any 
problem  for  which  the  knowledge  domain  is  factorable.  The 
architecture  is  not  affected  by  the  specific  nature  of  the 
problem. 

The  optimal  location  for  an  expert  system  on  the  network 
can  be  determined  by  minimizing  system  cost.  System  cost  has 
two  significant  components,  processing  cost  and  communication 
cost.  Communication  cost  is  straight-forward.  It  is  a  factor 
of  the  volume  of  communication,  C^j,  multiplied  by  the  cost 
per  unit  of  volume,  Ckl . 

Processing  cost,  q^k,  for  expert  systems  was  found  to  be 
a  function  of  the  number  of  rules  in  an  expert  system,  r^, 
the  level  of  coupling  among  the  rules,  s^,  and  the  power  of 
the  CPU  at  the  node,  tk.  The  relationship  is  the  formula: 

^ik  ”  ri  si  ^  fck 

Using  integer  programming,  minimum  total  system  cost  can 
be  obtained  by  minimizing  the  following  objective  function: 

Cost  -  IkZi[qijXij+IkI1(CijCklxikxjl)] 

The  end  result  is  a  magnitude  which  can  be  applied  to  expert 
systems  across  heterogeneous  processors.  Optimum  distribution 
is  important  to  both  system  design  and  tuning. 

2 .  FUTURE  RESEARCH 

The  group  expert  system  developed  in  this  thesis  is  a 
pioneering  model  used  to  prove  the  possibility  of 
implementing  group  expert  systems  on  a  PC  LAN,  to  demonstrate 
a  method  of  system  allocation,  and  to  propose  an  architecture 
for  group  expert  systems.  This  unique  prototype  is  limited  by 
the  purposes  for  which  it  was  created  and  the  environment  in 
which  it  was  implemented. 

Expansion  of  the  model  itself  offers  several  directions 
for  future  research.  To  make  the  GESP  system  practical  it 


should  be  implemented  on  a  distributed  operating  system.  The 
advent  of  multitasking  microcomputer  operating  systems,  such 
as  OS/2,  will  allow  calling  procedures  for  consultant  expert 
systems  to  be  efficient.  The  processor  need  not  be  dedicated 
to  a  polling  procedure  to  receive  information,  and  the  use  of 
a  blackboard  can  be  eliminated. 

In  a  distributed  environment  the  communication 
architecture  can  be  totally  generic.  There  will  be  no  need  to 
communicate  by  sending  problem-specific  files.  The  goal  is  to 
create  a  communication  ES  which  is  completely  problem- 
independent,  achieving  the  first  level  of  modularity. 
Adhering  to  a  modular  communication  structure  will  allow 
multiple  group  expert  systems  to  co-exist  on  the  network  and 
be  controlled  by  a  single  communication  expert  system,  CES . 
The  CES  will  know  of  all  other  expert  systems  in  the  GES  and 
of  all  problems  the  GES  is  capable  of  solving.  The  generic 
CES  can  be  located  at  any  or  all  nodes  in  the  network.  A  user 
can  then  enter  the  GES  from  any  node  and  solve  any  problem  in 
the  GES.  To  make  this  extension  from  the  GESP  system  one  must 
a  CES  separate  from  the  meta  ES.  It  is  the  meta  ES  that 
achieves  the  second  level  of  modularity,  the  factoring  of  the 
problem  domain,  and  synthesizes  the  problem  solution. 

The  ultimate  extension  of  this  study  would  be  the 
implementation  of  a  group  expert  system  on  a  Wide  Area 
Network.  Aside  from  the  obvious  differences  in  communication 
requirements,  the  implications  for  GES  and  individual  expert 
system  architecture  will  need  to  be  studied.  Wide  Area 
Network  GES  offer  tremendous  potential  support  for  both  the 
strategic  C^  environment  and  managerial  decision  making  in 
the  private  sector. 
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SOURCE  CODE  FOR  GESP 


/*  META.ARI  */ 

/*  database  */ 
base_t_b (time (0, 0,  0,  0)  )  . 
base_d_b (date (0,0,0)  )  . 
base_t_c (time (0,  0,  0, 0)  )  . 
base_d_c (date (0,0,0)) . 
base_t_d (time (0, 0, 0, 0) ) . 
base_d_d (date (0,0,0)) . 
base_t_e (time (0, 0, 0, 0) ) . 
base_d_e (date (0,0,0)). 
base_t_f (time (0, 0, 0, 0) ) . 
base_d_f (date (0,0,0)). 

member (Probs , [a,b,c,d,e,f]) . 
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consult_es (a, [crime_l , credit__l 3 ) . 
consult_es (b, [crime_l] ) . 
consult_es (c, [credit_l] ) . 
consult_es (d, [psych_l, credit_3) ) . 
consul t_es (e, [crime_l , credit_l, psych_l ] ) 
consult_es (f, [credit_3, crime_l , psych_l ] ) 

/*  rules  */ 

public  main/O. 


main : - 


prob_read, 
prob_features, 
prob__soln, 
f ind_soln, 

retract (prob_stmt (P-cb_Stmt) ) . 


/*  Do  this  last.  */ 
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prob_read: - 
nl, 

write ('input  problem  statement:'), 

read (Prob_Stmt ) , 

asserta (prob_stmt (Prob_Stmt) ) . 

prob_features : - 

call (prob_stmt (Prob_Stmt) ) , 

ifthenelse (member (Prob_Stmt, Probs) ,meta_a, exit) . 

member (X, [X | _] ) . 

member (X, [_| Y] ): -  member (X,Y). 

meta_a : - 

subfeatures  (E__Sys)  , 
put_k_files (E_Sys) , 
write ('kfile  written'). 

exit : - 

nl, write ('Could  not  interpret'). 

put_k_f iles (E_Sys) 

create (H3, ' k_fiie . inp' ) , 

write (H3, ' es ( ' ) , write (H3, E_Sys) , write (H3 , ' ) . ' ) , nl (H3) , 
close (H3) , 

shell ('copy  k_file.inp  c:'). 

subfeatures (E_Sys) 

call (prob_stmt (Prob_Stmt) ) , 
consult_es (Prob_Stmt, E_Sys) . 

prob_soln : - 

call (prob_stmt (Prob_Stmt) ) , 
ifthen (Prob_Stmt=a, report_a) ; 
ifthen  (Prob_Stmt=b,  report__b)  / 


if then (Prob_Stmt=c, report_c) 
ifthen (Prob_Stmt“d, report_d) 
if then (Prob_Stmt-e, report_e) 
ifthen (Prob_Stmt=f , report_f ) 

report_a : - 

get_crime_l , 
get_credit_l . 

report_b: - 

get_crime_l . 

report_c : - 

get_credit_l . 

report_d: - 

get_psych_l , 
get_credit_3 . 

report_e : - 

get_crime_l , 
get_credit_l . 

report_f : - 

get_crime_l , 
get_credit_3, 
get_psych_l . 

get_crime_l : - 

directory ( ' c : \crime_l . rep' , 

base_time_b, 

base_date_bf 

new_time_b (T)  , 

new_date_b (D)  , 

asserta(base  d  b(D)), 
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asserta (base_t_b (T)  )  , 
shell ('copy  c:  crime_l . rep' ) , 
open (H, '  crime_l . rep'  ,  r)  , 
read_val (H)  , 
close (H)  . 

get_credit_l : - 

directory ('  c : \credit_l . rep' T,  D,_)  , 

basest ime_c, 

base_date_c, 

new_time_c (T) , 

new_date_c (D) , 

asserta (base_d_c (D) )  , 

asserta (base_t_c (T) )  , 

shell ('copy  c:  credit_l . rep' )  , 

open (H, ' credit_l . rep' ,  r)  , 

read_val (H)  , 

close (H) . 

get_psych_l :  - 

directory  ( '  c:  \psych_l .  rep' T,  D,_)  , 

base_time_d, 

base_date_d, 

new_time_d (T)  , 

new_date_d (D) , 

asserta  (base_d__d  (D) ) , 

asserta (base_t_d (T) )  , 

shell ('copy  c:  psych_l . rep' ) , 

open (H, ' psych_l . rep' , r) , 

read_val (H) , 

close (H) . 

get_credit_2 : - 

directory  ( '  c  :  \credit_2  .  rep'  (_,_fT,D,J  , 
base_time_e, 
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base_date_e, 
new_time_e (T) 
new_date_e (D) , 
asserta (base_d_e (D) ) , 
asserta (base_t_e (T) ) , 
shell {'copy  c:  credit_2 . rep' )  , 
open (H, '  credit_2 . rep' ,  r)  , 
read_val (H) , 
close (H) . 

get_credit_3 :  - 

directory ( '  c : \credit_3 . rep' 

base_time_f , 

base_date_f , 

new_time_f (T)  , 

new_date_f (D)  , 

asserta (base_d_f (D) ) , 

asserta (base_t_f (T) ) , 

shell ('copy  c:  credit_3 . rep' ) , 

open (H, ' credit_3 , rep' , r) , 

read_val (H) , 

close  (H) . 

base_time_b: -  base_t_b (time (W, Xf  Yf Z) ) 
base_date_b : -  base_d_b (date (X, Yf Z) ) . 
base_time_c : -  base_t_c (time (W, X, Y, Z ) ) 
base_date_c : -  base_d_c (date (X, Y, Z) ) . 
base  time  d:-  base  t  d (time (W, X, Y, Z) ) 


base  date  d:-  base  d  d (date (X, Y, Z) ) . 


base_time_e : -  base_t_e (time (W, X, Y, Z) ) . 

base_date_e : -  base_d_e (date (X, Y, Z) ) . 

base_time_f : -  base_t_f (time (W, X, Y, Z) ) . 

base_date_f : -  base_d_f (date (X, Y, Z) ) . 

new_time_b (T) 

base_t_b (B_T) , 

ifthenelse (T*B_T, keep_looking_k, set_new_time) 

new_date_b (D) 

base_d_b(B_D) , 

ifthenelse (D-B_D, keep_looking_k, set_new_date) 

new_time_c (T)  :  - 

base_t_c (B_T) , 

ifthenelse (T=B_T, keep_looking_k, set_new_time) 

new_date_c (D) : - 

base_d_c (B_D) , 

ifthenelse (D=B_D, keep_looking_k, set_new_date) 

new_time_d (T) 

base_t_d (B_T)  , 

ifthenelse (T-B_T, keep_looking_kf  set_new__time) 

new_date_d (D) 

base_d_d (B_D) , 

ifthenelse (D-B_D, keep_looking_k, set_new_date) 


new_time_e (T) : - 

base_t_e (B_T) , 

ifthenelse (T=B_T, keep_looking_k, set_new_time) 
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new  date  e (D) : - 


base_d_e (B_D) , 

ifthenelse (D=B_D, keep_looking_k, set_new_date) . 

new_time__f  (T)  :  - 

base_t_f  (B_T)  , 

ifthenelse  (T=B_T,  keep_looking_k,  set_new_time)  . 

new_date_f (D) 

base_d_f (B_D) , 

ifthenelse (D=B_D, keep_looking_k, set_new_date) . 

set_new_time : -  retract (base_t_b (time (W, X,  Y, Z) )  )  . 

set_new_date : -  retract (base_d_b (date (X, Y, Z ) ) ) . 

set_new_time : -  retract (base_t_c (time (W, X, Y, Z) ) ) . 

set_new_date : -  retract (base_d_c (date (X, Y, Z) ) ) . 

set_new_time : -  retract (base_t_d (time (W, Xf Y, Z) ) ) . 

set_new_date : -  retract (base_d_d (date (X, Y, Z )) ) . 

set_new_time : -  retract (base_t_e (time (W, X, Y, Z) ) ) . 

set_new_date : -  retract (base_d_e (date (X, Y, Z) ) ) . 

set_new_time : -  retract (base_t_f (time (W, X, Y, Z) ) ) . 

set_new_date : -  retract (base_d_f (time (X, Y, Z) ) ) . 

read_val (H) : - 
repeat, 

54 


read (H, T) , 
asserta (T) , 
recordz (val, T,  _) , 
T=end  of  file. 


f ind_soln : - 
add. 


add :  - 


findall (X, score (X) , L) , 

L-[L1, L2] , 

Total  is  L1+L2, 
write (Total) , 

ifthen (Total>300, action_l) ; 
ifthen (Ll>160, action_l) ; 
ifthen (L2>180, action_l) ; 
ifthen (Total~<300, action_2) ; 
ifthen (Ll=<160, action_2) ; 
ifthen (L2~<180, action  2). 


action  1:- 


write (' Further  investigation  required.'). 


action_2 : - 

write (' Subject  requires  no  further  investigation.') 

keep_looking_k : - 
prob_soln . 

/*  end  META.ARI  */ 
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/*  CRIME_1 . ARI  */ 

/*  database  */ 

base_t (time (0, 0,0,0) ) . 
base_d (date (0, 0,0)) . 

/*  rules  */ 

public  main/O. 
main : - 

directory  ('c:\k_file.inp' T,D,_) , 

base_t ime, 

base_date, 

new_time (T)  , 

new_date  (D) , 

asserta (base_d (D) ) , 

asserta (base_t (T) ) , 

shell ('copy  c : k_f ile . inp' ) , 

open (H, ' k_f ile . inp' , r)  , 

read_val (H) , 

close (H) , 

( (  find_soln, 
calc_soln, 
report_meta  )  ; 
keep_looking_k) . 

base_time : -  base_t (time (W, X, Y, Z) ) . 

base_date:-  base_d (date (X, Y, Z) ) . 

new_t ime (T) : - 

base_t (B_T) , 

ifthenelse (T*B_T, keep_looking_k, set_new_t ime) 

new_date (D) : - 

base  d (B  D) , 
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ifthenelse (D~B_D, keep_looking_k, set_new_date) . 

set_new_time : -  retract (base_t (time (W, X, Y, Z) ) ) . 

set_new_date : -  retract (base_d (date (X, Y, Z) ) ) . 

read_val ( H ) : — 
repeat, 
read (H, T) , 
asserta (T) , 
recordz (val, T, _) , 

T=end_of_f ile . 

f ind_soln : - 

f ind_es (E_Sys) . 

f ind_es (E_Sys) 

call (es (E_Sys) ) , 
member (crime_l, E_Sys) . 

calc_soln:-  asserta (score (180) ) . 

/*  A  score  of  180  is  asserted  for  demo  purposes.  */ 

/*  The  actual  criminal  database  would  be  called  here.  */ 

member (X, [X | _] ) . 

member (X, [ _ I Y ] ) : -  member (X, Y) . 

report_meta : - 

call (score (X) ) , 

create (H3, '  crime_l . rep' ) , 

write (H3, ' score ( ' ) , write (H3,X) , write (H3, ' ) . ' ) , nl (H3) , 
close (H3) , 

shell ('copy  crime_l . rep  c:'), 
keep_looking_k . 


/*  CREDIT_1 . ARI  */ 

/*  database  */ 

base_t (time (0, 0, 0, 0) ) . 
base_d (date (0,0,0)  )  . 
base_t_c (time (0, 0,  0,  0)  )  . 
base_d_c ( date (0,0,0)). 

/*  rules  */ 

public  main/O. 
main :  - 

directory ( '  c : \k_f ile . inp' , T,  D, _) , 

base_time, 

base_date, 

new_time (T)  , 

new_date (D)  , 

asserta (base_d (D) )  , 

asserta (base_t (T) ) , 

shell ('copy  c : k_f ile . inp' )  , 

open (H, ' k_f ile . inp' , r) , 

read_val (H) , 

close (H) , 

( (  find_soln, 

reportjmeta  )  ; 
keep_looking_k) . 

base_time : -  base_t (time (W, X, Y, Z) ) . 

base_date:-  base_d (date (X, Y, Z) ) . 

new_time (T) : - 

base_t (B_T) , 

ifthenelse (T~B_T, keep_looking_k, set_new_time) 
new  date (D) : - 
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base_d (B_D) , 

ifthenelse  (D«B_D, keep_looking_k, set_new_date) . 

set_new_time : -  retract (base_t (time (W, X, Y, Z) ) ) . 

set_new_date : -  retract (base_d (date (X, Y, Z)  )  ) . 

read_val (H) : - 
repeat, 
read (H, T) , 
asserta (T) , 
recordz (val, T,_)  , 

T=end_of_f ile . 

f ind_soln : - 

find_es (E_Sys) , 
calc_soln . 

f ind_es (E_Sys) 

call (es (E_Sys) )  , 
member (credit_l , E_Sys) . 

member (X, [X (_] ) . 

member (X, [_ | Y] ): -  member (X,Y). 

calc_soln : - 

/*  do  credit  calc  &  insert  X  for  161  */ 
asserta (score_l (161) ) , 
call (score_l (161) )  , 

ifthenelse (score_l (161) >160, get_credit_2,put_score_l) . 

put_score_l : - 

/*  call (score_l (161)  , 

S= ( 1 61 ) , 

asserta (score  (161) ) ,  */ 


report_meta . 

get_credit_2 : - 

put_k_f iles , 
write('kfile  written'). 
get_k_files, 
calc_consult . 

calc_consult : - 

call (score_l (X) )  , 
call (score_2 (Y) ) , 

ifthenelse (score_2 (Y) >score_l (X) , put_score_- 
2, put_score_l ) . 

put_k_f iles : - 

create (H4 , ' credit_l . inp' ) , 

write (H4, ' es (' ) , write (H4, credit_2) , write (H4, nl (H- 
4)  , 

close (H4 ) , 

shell ('copy  credit_l . inp  c:'). 
get_k_files : - 

directory (' c : \credit_2 . rep' , T, D,_)  , 

base_t ime_c, 

base_date_c, 

new_time_c (T)  , 

new_date_c (D) , 

asserta (base_d_c (D) ) , 

asserta (base_t_c (T)  )  , 

shell ('copy  c:  credit_2 . rep' ) , 

open  (H, ' credit_2 . rep'  ,  r)  , 

read_val_c (H) , 

close (H) . 

base_time_c : -  base_t_c (time (W, X,  Y, Z)  ) . 
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base_date_c : -  base_d_c (date (X, Y, Z ) ) . 

new_t ime_c (T) 

base_t_c (B_T)  , 

ifthenelse (T=B_T, keep_looking_k, set_new_time_c) . 

new_date_c (D) 

base_d_c (B_D)  , 

ifthenelse (D«B_D, keep_looking_k, set_new_date_c) . 

set_new_time_c : -  retract (base_t_c (time  fW,X, Y, Z) ) ) • 

set_new_date_c : -  retract (base_d_c (date iX, Y, Z) ) ) . 

read_val_c (H) 
repeat, 
read (H, T) , 
asserta (T) , 
recordz (val, T,_) , 

T=end_of_f ile . 

report_meta : - 

call (score (X) ) , 

create (H3,  '  credit_l . rep' ) , 

write (H3, ' score (' ) , write (H3,X) , write (H3, ' )  . '  )  ,nl (H3)  , 
close (H3) , 

shell ('copy  credit_l.rep  c:'), 
keep_looking_k . 

keep_looking_k : - 
main . 


► 


V, 

% 


/*  end  CREDIT  l.ARI  */ 
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CREDIT_2 . ARI  */ 

database  */ 
base_t {time (0, 0, 0, 0) ) 
base_d (date (0, 0,0)) . 


rules 
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public  main/O. 
main : - 

directory ( '  c : \credit_l .inp' , T, D, _) , 

base_time, 

base_date, 

new_time (T) , 

new_date (D) , 

asserta (base_d (D) ) , 

asserta (base_t (T) ) , 

shell ('copy  c : credit_l . inp' ) , 

open (H, ' credit_l . inp' , r) , 

read_val (H)  , 

close  (H) , 

( {  find_soln, 
calc_soln, 
report_meta  )  ; 
keep_looking_k)  . 


base  time:-  base  t (time (W, X, Y, Z) ) 


base  date:-  base  d (date (X, Y, Z ) ) 


new_t ime (T) : - 

base  st  (B_T) , 

ifthenelse (T>B_T, keep_looking_k, set_new_t ime) 


new_date (D) : - 

base  d (B  D) , 
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ifthenelse (D-B_D, keep_looking_k, set_new_date) . 

set_new_time : -  retract (base_t (time (W, X,  Y, Z)  )  ) . 

set_new_date : -  retract (base_d (date (X, Y, Z) ) ) . 

read_val (H) : - 
repeat, 
read (H, T) , 
asserta (T) , 
recordz (val, T,_) , 

T*end_of_f ile . 

f ind_soln : - 

find_es (E_Sys) . 

f ind_es (E_Sys) 

call (es (E_Sys ) ) , 
member (credit_l, E_Sys) . 

calc_soln:-  asserta ( score ( 160) ) . 

/*  A  score  of  160  is  asserted  for  demo  purposes.  */ 

/*  The  actual  credit  database  would  be  called  here  */ 

member (X, [X | _ ] ) . 

member (X, [_ | Y] ): -  member (X,Y). 

report_meta : - 

call (score (X) ) , 

create (H3, '  credit_2 . rep' ) , 

write (H3, ’  score ( ' ) , write (H3, X) , write (H3, ' ) . ' ) , nl (H3) , 
close (H3) , 

shell ('copy  credit_2.rep  c:'), 
ke-  _looking_k. 


! 

? 


e 


m 


.V  .V.I .*>>  :ii< 


.i.r'ii;  \  '  i’d*  - 


/*  CREDIT_3 . ARI  */ 

/*  database  */ 

base_t (time (0, 0,0,0)) . 
base_d (date (0, 0,0)) . 

/*  rules  */ 

public  main/O. 
main : - 

directory ( '  c : \k_f ile . inp' T,  D,_) , 

base_time, 

base_date, 

new_time (T)  , 

new_date (D) , 

asserta (base_d (D) ) , 

asserta  (base__t  (T)  )  , 

shell ('copy  c : k_f ile . inp' ) , 

open (H, ' k_f ile . inp' ,  r) , 

read_val (H) , 

close (H) , 

( (  find_soln, 
calc_soln, 
report_meta  )  ; 
keep_looking_k) . 

base_time: -  base_t (time (W, x, Y, Z) ) . 

base_date:-  base_d (date (X, Y, Z) ) . 

new_time (T)  :  - 

base_t (B_T) , 

ifthenelse (T»B_T, keep_looking_k, set_new_time) 

new_date ( D ) : — 

base  d (B  D) , 
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lfthenelse (D=B_D, keep_looking_k, set_new_date) . 

set_new_time:-  retract (base_t (time (W, X, Y, Z) ) ) . 

set_new_date:-  retract (base_d (date (X, Y, Z) ) ) . 

read_val (H) : - 
repeat, 
read (H, T) , 
asserta (T) , 
recordz (val, T,_)  , 

T=end_of_file. 

f ind_soln : - 

find_es (E_Sys) . 

f ind_es (E_Sys) 

call (es (E_Sys) ) , 
member (credit_3,E_Sys) . 

calc_soln:-  asserta (score (160) ) . 

/*  A  score  of  160  is  asserted  for  demo  purposes.  */ 

/*  The  actual  credit  database  should  be  called  here.  */ 

member  (X,  [X|_J  )  . 

member (X, [_|Y]):-  member (X,Y). 

report__meta :  - 

call  (score (X) ) , 

create (H3 , ' crdeit_3 . rep' ) , 

write  (H3, ' score ( ' ) , write (H3, X) , write (H3, nl (H3)  , 
close (H3) , 

shell  ('copy  credit__3  .  rep  c:'), 
keep_looking_k . 
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/*  PSYCH_1 . ARI  */ 

/*  database  */ 

base_t (time (0, 0, 0, 0) ) . 
base_d (date (0,0,0) ) . 

/*  rules  */ 

public  main/O. 
main : - 

directory  ( '  c :  \k_f ile .  inp'  ,  _,  _,  T,  D,  _)  , 

base_time, 

base_date, 

new_time (T) , 

new_date (D) , 

asserta (base_d (D) ) , 

asserta (base_t (T) ) , 

shell ('copy  c : k_f ile . inp' ) , 

open (H, ' k_file. inp' , r) , 

read_val (H) , 

close (H) , 

( (  find_soln, 
calc_soln, 
report_meta  )  ; 
keep_looking_k) . 

base_time : -  base_t (time (W, X, Y, Z) ) . 

base_date:-  base_d (date (X, Y, Z) ) . 

new_time (T) : - 

base_t (B_T) , 

ifthenelse (T-B_T, keep_looking_k, set_new_time) 

new_date  (D)  :  - 

base  d (B  D) , 
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ifthenelse  (D-B_D,  keep_looking_)c,  set_new_date)  . 

set_new_time : -  retract (base_t (time (W, X, Y, Z) ) ) . 

set_new_date : -  retract (base_d (date (X, Y, Z) ) ) . 

read_val ( H ) : — 
repeat, 
read (H, T) , 
asserta  (T) , 
recordz (val, T,_) , 

T=end_of_f ile . 

f ind_soln : - 

f ind_es (E_Sys) . 

f ind_es (E_Sys) 

call (es (E_Sys) ) , 
member (psych_l, E_Sy s) . 

calc_soln:-  asserta (score (170) ) . 

/*  A  score  of  170  is  asserted  for  demo  purposes.  */ 

/*  The  actual  psychological  database  should  be  called  here 


member  (X,  [X  |_J  )  . 

member (X, [_ | Y] ): -  member (X,Y). 

report_meta : - 

call (score (X) ) , 

create (H3 , ' psych_l . rep' ) , 

write (H3, ' score ( ' ) , write (H3 , X) , write (H3 , ' ) . ' ) , nl (H3) , 
close (H3) , 

shell ('copy  psych_l.rep  c:'). 


Ukl 


keep_looking_k . 


keep_looking_k : - 
main . 

/* 


End  PSYCH  l.ARI 
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